home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 6828 < prev    next >
Encoding:
Text File  |  1996-08-05  |  2.5 KB  |  62 lines
  1. Newsgroups: comp.lang.c++
  2. Path: netcom.com!hester
  3. From: hester@netcom.com (Jim Hester)
  4. Subject: [Borland's?] new: xalloc exception shoots itself in the foot?
  5. Message-ID: <hesterDn1F1H.LKr@netcom.com>
  6. Organization: NETCOM On-line Communication Services (408 261-4700 guest)
  7. Distribution: usa
  8. Date: Mon, 19 Feb 1996 19:20:05 GMT
  9. Sender: hester@netcom9.netcom.com
  10.  
  11. This may be Borland specific:
  12.  
  13. I recently ran a program that allocated a lot of small nodes (I was
  14. performing a breadth-first search of my hard drive) and ran out of
  15. space.  My system locked up.  My best guess (experimentation appears to
  16. support this) is that this is what happened:
  17.  
  18. The "new" operator threw an xalloc exception.  xalloc contains a string
  19. class object, which attempts to allocate an array of chars.  Since there
  20. was no memory available, another xalloc exception was thrown and the
  21. "exception loop" continued.
  22.  
  23. Am I missing something, or is this as stupid as it appears to be?
  24. What possible justification could there be for having the default
  25. action of allocation failure be to try allocating again?
  26.  
  27. In the case of memory exceptions, I tend to try to trap them as early as
  28. possible and throw an equivalent exception with a more descriptive
  29. string giving the location of the fault.  Each layer up from there I
  30. again try to trap and add information ONLY if it wasn't added at a
  31. deeper layer (that way I get the closest approximation to where the
  32. error actually occurred).  I can save run-time problems with this
  33. practice to some extent by keeping static exception objects at each
  34. place where I might want them, pre-initialized with appropriate strings.
  35. However, this doesn't help at all with the FIRST exception: the one that
  36. is actually thrown by the "new" operator.
  37.  
  38. I understand that I can override the "exceptional" behavior and
  39. re-institute a nice safe NULL return policy.  My purpose here is one of
  40. curiosity (and in case I've missed something).  What were the designers
  41. thinking????
  42.  
  43. Thanks in advance,
  44.      _
  45.     / )                 *
  46.    (_/  . __            /
  47.   / /\_/_///_          |
  48.  (_/                   |
  49.                        |\
  50.                 *      |  \      *
  51.                        |    \
  52.                        | \    \
  53.                        |   \/   \/
  54.                       /
  55.                         *
  56. Redundency avoided: look my address up in the message headers.
  57. Oops, the line above wasts even more space than my address would have!
  58. Oh, My!!!  I wasted even MORE space!!
  59. AAAcccckkkkk!  I did it AGAIN!!!!!
  60. (Sorry, I was got back from a convention where Monty Python references
  61. were prevalent.)
  62.